Traditionally, policy management for telecommunication networks has focused mainly on network management. In recent years, however, as wireless networks have migrated towards Internet Protocol (IP)-based service environments, policy management has been gaining increasing importance to telecommunication networks wishing to manage and control those services.
In this regard, today, when a user of a networked portable device, such as a cell phone, PDA, laptop, or the like, request(s) access to one or more services offered via one or more networks, there is no common way to access and apply policy to the user requests. For a similar reason, there is no common way to manage, i.e., store, update, etc., the policies in the system either. Each separate service, or class of services, today requires the network to apply different policy mechanisms depending on the kind of request being handled.
For instance, as shown in FIG. 8, where a user makes a request via a portable device 800 for short messaging services (SMS) via network(s) 810, the user's request today is forwarded to a policy management subsystem 820 coupled to policy storage 822 for storing SMS policies of the network. In this regard, the policy management subsystem 820 and SMS policy storage 822 are customized for SMS policies and rules for enforcing those SMS policies. Similarly, where a user might make a request for Internet service via network(s) 810, the user's request is referred to a policy management subsystem 830 coupled to policy storage 832 for storing rules applying to Internet usage. The policy management subsystem 830 and Internet policy storage 832 are customized for Internet policies and rules for enforcing those SMS policies.
Since the rules are customized for particular classes of services, the rule subsystems cannot be re-used for new classes of services, and do not interoperate with one another easily. Moreover, in addition to storage 822 and 832 being stored at different locations, and according to different formats, different rule definitions, etc., storage 822 or 832 might each themselves be stored in a distributed manner, storing policy information across a network at various different nodes and locations. Thus, management of this policy information, even within the same network, presents difficult issues.
As yet another example, the user might make another request for Location services, which may be offered on second network(s) 812 via network(s) 810, e.g., as in the roaming case for disparate network domains. In such a case, the user's request is referred to yet another policy management subsystem 840 accessible only via second network(s) 812, which is coupled to yet another policy storage 842 for storing rules applying to Location services usage on second network(s) 812. The policy management subsystem 840 and Location policy storage 842 are customized for Location policies and rules for enforcing those Location policies.
It would be desirable to transmit one or more policies pertaining to the user from somewhere within the domain of network(s) 810 to network(s) 812 so that policies can be used interchangeably between the networks. However, today, the policy management subsystems 820 and 830 simply do not communicate such policy information between networks due to the above-described complexity associated with numerous ever-evolving classes of services, each implementing custom policy management and storage for dynamic and static policies.
Thus, currently, these policy management functions are scattered within mobile networks. These ad hoc implementations of policy functions lead to policy conflicts, driving up operating expenses (OPEX) and complexity. Today, due to such customized and distributed storage, management and application of policies for different classes of services, policy management is not applied in a coherent manner.
As the number of classes of services proliferates, the problems presented by the lack of centralized policy repository and management system increase exponentially. Furthermore, there is no existing mechanism to exchange policy information from such a centralized repository for roamers on a network, so that a user's policy information can be accessible, in aggregate, for all of the services to which a user can subscribe across a variety of disparate networks.
These and other deficiencies in the state of the art of network traffic policy management and storage will become apparent upon description of the various exemplary non-limiting embodiments of the invention set forth in more detail below.